کلاهبرداری در پروژه های ساختمانی در منطقه 22 تهران متاسفانه در سال های گذشته تعداد تعاونی های مسکن در منطقه 22 تهران بصورت غیر قابل باوری رو به افزایش میباشد تعاونی هایی که بدون هیچ گونه سابقه کاری و هیچ گونه سابقه کاری و رزومه دست به عضو گیری  از افراد بی اطلاع و نا اگاه که بدون  هیچ گونه شناختی از تعاونی ها انجام داده اند بخاطر شکل و فرمت قرارداد های تعاونی های مسکن و شرایط خاصی که قرارداد تعاونی ها مسکن دارند دست به کلاهبرداری در منطقه 22 تهران میزنند البته کلاهبرداری که کاملا شکل و فرمت قانون دارد و شما بصورت قانونی نمیتوانید اقدام خاصی انجام دهید و در نهایت با بعد ازچند سال دوندگی های مسیر قانونی نهایت به پول خود خواهید رسید شرایطی که در تعاونی های مسکن دست کلاهبرداران را باز میگذارد 1- باز بودن قیمت ساخت در تعاونی های مسکن  قیمت ساخت علی الحساب که در تعاونی ها ی مسکن امری بسیار عادی میباشد از آنجایی که تعاونی مسکن بایستی با قیمت ساخت تمام شده واحد اپارتمان را تحویل اعضا دهد و نبایستی بغیز از چند درصد ناچیز آن هم بعنوان حق بالاسرس برای پرداخت هزینه های تعاونی دریافت کند بازیچه کلاهبرداری کلاهبرداران در منطقه 22 تهران شده است وتا حدی که در بعضی از تعاونی های مسکن قیمت زمین و تراکم را در قرارداد بصورت علی الحساب محاسبه میکنند 2- عدم مشخص بودن زمان تحویل پروژه در قرارداد در قرارداد تعاونی ها بند های آمده است که زمان تحویل پروژه را  بصورت مشخص شده است اما معمولا ضرر و زیان مناسبی برای تاخیر تحویل مشخص نمیشود و یا با چند بند دیگر  شرایطی برای پرداخت ضررو زیان مشخص میکنند این امر نیز در تعاونی های مسکن از آنجایی که بایستی با پرداختی اعضا ساخته شود و

همانطور که می دانید از نسخه 12cR1، دیتابیس اوراکل از JSON پشتیبانی می کند به این معنی که با ارائه چندین تابع، امکان انجام عملیاتی چون اجرای query، ایجاد index و ایجاد view را بر روی فیلدهای JSON Document فراهم می کند. البته در این نسخه ها(تا قبل از اوراکل 21)، Data Type جدیدی برای JSON معرفی نشده و JSON Documentها باید در نوع داده VARCHAR2، CLOB و یا BLOB ذخیره شوند(نوع داده NCLOB و NVARCHAR2 را هم باید به این مجموعه اضافه کرد) که معمولا نوع داده BLOB برای این کار توصیه می شود(مطالعه مطلب “JSON و دیتابیس اوراکل” پیشنهاد می شود). SQL> create table tbl_JSON_12c (id number,ettelaat varchar2(4000)  constraint jc1 check (ettelaat is json) ); SQL> insert into tbl_JSON_12c values(2,'{“First_Name”:”Vahid”,”Last_Name”:”Usefzadeh”,”Contact”:{“Email”:”[email protected]”,”Phone”:”091111111117″}}’); 1 row inserted SQL> select t.ETTELAAT.Last_Name,t.ETTELAAT.Contact.Email from tbl_JSON_12c t; LAST_NAME         CONTACT ————–  —————————- Usefzadeh        [email protected] اوراکل در نسخه 21c، نوع داده JSON را معرفی کرده است: SQL> create table tbl_JSON_21c (id number, ettelaat  json) ; Table created. SQL> insert into usef.tbl_JSON_21c values(2,'{"First_Name":"Vahid","Last_Name":"Usefzadeh","Contact":{"Email":"[email protected]","Phone":"091111111117"}}'); 1 row created. اطلاعات در این نوع از داده، به صورت باینری ذخیره می شوند: SQL> select *&nb

همانطور که می دانید، از طریق قابلیت (Automatic Data Optimization (ADO می توان سیاستهایی را بر اساس آمارهای دستیابی و اصلاح segmentها، برای کاهش فضای مصرفی و بهبود کارایی اعمال کرد برای مثال با فشرده سازی جداولی که کمتر مورد اصلاح و یا دستیابی قرار می گیرند و نیز انتقال segmentهای کم طرفدار به دیسک با هزینه کمتر، می توان قدمهایی را در زمینه بهینه سازی برداشت. ADO در اوراکل نسخه 12c ارائه شد و بعدا در هر کدام از نسخه ها، قابلیتهای جدیدی به آن اضافه شد که در این مطلب، به قابلیت جدید اوراکل نسخه 21c در این زمینه خواهیم پرداخت. در این نسخه می توان با کمک ADO برای ایندکسها پالیسیهایی را وضع کرد مثلا می توان بر اساس تاریخ آخرین زمان دستیابی و اصلاح، در سه سطح فشرده سازی(compressing)، بازسازی(rebuilding) و کاهش حجم(shrinking) قوانینی را اعمال نمود. برای استفاده از این فیچر، باید قابلیت HEAT_MAP را فعال کنیم تا اوراکل با ثبت data access و data modification آمار فعالیتهای مربوط به ایندکس را(همانند جداول و بقیه segmentها) جمع آوری کرده و زیر نظر داشته باشد. در ادامه پالیسی ای را با طی چند مرحله ایجاد خواهیم کرد که بر اساس آن، اگر به ایندکسی به مدت 4 روز رجوع نشود(no access)، ایندکس optimize شود. optimize می تواند یکی از عملیات فوق(compressing، rebuilding و shrinking) باشد که تصمیم گیری آن با خود اوراکل است. 1.در قدم اول، برای استفاده از قابلیت ADO، باید پارامتر HEAT_MAP را به مقدار ON تنظیم کنیم. SQL> alter system set heat_map=ON; System altered توجه: برای مشاهده آمارهای جمع آوری شده توسط قابلیت HEAT MAP، می توان از ویوی V$HEAT_MAP_SEGMENT استفاده کرد(مطالعه بیشتر).   2.جدول و

GIMR یا همان Grid Infrastructure Management Repository در اوراکل 12c ارائه شد و هدف اوراکل از ارائه GIMR، ثبت وقایع و رخدادهای مربوط به کلاستر می باشد به طور دقیق تر، GIMR قرار است Cluster Health Monitor را در دیتابیسش ثبت کند. این دیتابیس حدودا 20 جدول دارد که لیست جداول آن را می توان به روش زیر مشاهده کرد: [grid@RAC1 ~]$ export ORACLE_SID=-MGMTDB [grid@RAC1 ~]$ sqlplus "/as sysdba" SQL> alter session set container=GIMR_DSCREP_10; Session altered. SQL> select table_name from dba_tables where owner='CHM' order by table_name; TABLE_NAME -------------------------------------------------------------------------------- CATCHMUTILPLS_PARTITION_TMP_TBL CHMOS_ACTIVE_CONFIG_INT_TBL CHMOS_ADVM_INT_TBL … 16 rows selected. به طور نمونه، با استفاده از جدول CHMOS_SYSTEM_SAMPLE_INT_TBL می توان اطلاعاتی را در مورد DISK IO بدست آورد: select to_char(begintime, 'YYYY/MM/DD HH24:mi:ss', 'NLS_CALENDAR=persian') begintime, round(DISK_BYTESREADPERSEC / 1024 / 1024) as MB_READ_SEC, round(DISK_BYTESWRITTENPERSEC / 1024 / 1024) as MB_WRITE_SEC, round(DISK_NUMIOSPERSEC) as IO_PER_SEC from CHM.CHMOS_SYSTEM_SAMPLE_INT_TBL order by IO_PER_SEC ; BEGINTIME MB_READ_SEC MB_WRITE_SEC IO_PER_SEC ------------------- ----------- ------------ ---------- 1400/11/03 09:53:20 14 147 856 1400/11/01 06:58:45 815 0 858 1400/11/01 06:39:55 314 2 858 1400/11/04 09:33:00 23 3 85